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Executive  Summary: 

The  SBCT  Embedded  Data  Collection  and  Analysis  System  (SEDCAS)  program  involved  the 
collection  and  analysis  of  individual  vehicle  fault  indication,  usage  and  performance  data  to 
improve  the  vehicle  fleet  sustainment  and  condition  based  maintenance  of  Stryker  Brigade 
Combat  Team  (SBCT)  vehicles  including  the  Stryker  and  HEMTT  A4  platforms.  The  56th  SBCT 
of  the  28th  Infantry  Division  of  the  Pennsylvania  Army  National  Guard  (PAARNG)  was  selected 
as  the  test  unit  for  this  program. 

The  focus  of  the  program  was  to  utilize  existing  GOTS  (primary  objective)  and  COTS 
(secondary  objective)  technologies  to  enable  an  automated  health  management  and  condition 
based  maintenance  capability  for  the  Stryker  platforms.  The  automated  system  is  designed  to 
operate  with  any  ground  vehicle  that  has  a  SAE  standard  digital  data  bus  including  the  Stryker, 
HEMTT,  FMTV,  HET,  M915  and  MRAPS. 

The  preliminary  work  for  this  program  involved  conducting  a  Stryker  vehicle  degrader  analysis 
to  determine  where  the  application  of  diagnostic  and  predictive  technologies  could  potentially 
have  the  greatest  impact  on  the  effective  implementation  of  condition  based  maintenance.  The 
degrader  process  for  the  Stryker  platform  used  data  from  three  sources  including:  multi-year 
part  replacement  data  from  DMIS  and  single  year  data  from  AMSAA,  maintainer  interviews,  and 
an  OEM  questionnaire  completed  by  GDLS-Canada.  The  results  of  the  degrader  analysis 
include  a  list  of  components  and  systems  that  could  benefit  from  health  management 
technologies  because  they  contribute  most  to  maintainability,  reliability  and  vehicle  operational 
availability  issues. 

The  program  functional  requirements  for  the  vehicle  embedded  digital  source  collection  (DSC) 
system  included  the  ability  to  interface  with  the  vehicle  digital  data  buses,  collect  vehicle  digital 
bus  data,  conduct  short  term  data  storage  (~  three  weeks),  enable  conversion  of  the  data  into 
the  standard  Army  Bulk  CBM  Data  (ABCD)  format,  and  wireless  data  transfer  from  vehicle  to 
remote  wireless  access  points  using  FIPS  140-2  data  encryption.  This  functionality  was 
implemented  with  a  maintenance  support  device  (MSD  v3)  with  additional  GOTS  and  COTS 
software.  The  DSC  gathers  vehicle  data  from  the  SAE  J1708  digital  data  bus,  the  SAE  J1939 
controller  area  network  (CAN)  bus  and  several  additional  digital  sensors  that  were  designed  for 
this  program.  The  wireless  local  area  network  (WLAN)  data  transmission  capability  that  moves 
data  from  each  platform  to  the  ARL  Information  Warehouse  (ARL  IW)  located  at  ARL  Penn 
State  consists  of  a  U.S.  Army  standard  (GOTS)  portable  WLAN  network  communication  system 
called  Combat  Service  Support  Automated  Information  Systems  Interface  (CAISI). 

Once  the  vehicle  data  is  received  by  the  bridge  module  located  at  ARL  Penn  State,  the  data  is 
ingested  into  the  ARL  Information  Warehouse.  This  server  system  was  designed  to  be  similar 
to  the  Common  CBM  Data  Warehouse  that  is  part  of  the  LOGSA  Logistic  Information 
Warehouse  (LIW).  This  was  done  to  develop  ‘best  practices’  for  moving  vehicle  data  to  LOGSA 
and  to  implement  technologies  that  are  currently  being  developed  and  deployed  by  DoD.  The 
general  functionality  of  the  ARL  IW  is  to  automatically  analyze  individual  ABCD  files  as  they 
arrive  at  the  IW  using  data  analytic  techniques.  The  SBCT  Unit  Management  Portal  user 
interfaces  were  designed  and  implemented  through  a  functioning  web  based  application. 

As  of  the  conclusion  of  this  project,  the  SEDCAS  system  remains  automated  and  operational 
with  five  Strykers  and  one  HEMTT  equipped  with  data  source  collection  systems,  a  functional 
wireless  off-board  data  transfer  system,  off-board  data  storage,  data  handling  system  and  the 
graphical  user  interface  available  for  viewing. 
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1.0  Degrader  Analysis  Summary:  Stryker  Platform 

A  Stryker  vehicle  degrader  analysis  was  conducted  to  determine  where  the  application  of 
diagnostic  and  predictive  technologies  could  potentially  have  the  greatest  impact  on  the 
effective  implementation  of  condition  based  maintenance.  The  degrader  process  for  the  Stryker 
platform  used  data  from  three  sources  including:  multi-year  part  replacement  data  from  DMIS 
and  single  year  data  from  AMSAA,  maintainer  interviews,  and  an  OEM  questionnaire  completed 
by  GDLS-Canada.  The  results  of  the  degrader  analysis  include  a  list  of  components  and 
systems  that  could  benefit  from  health  management  technologies  because  they  contribute  most 
to  maintainability,  reliability  and  vehicle  operational  availability  issues.  The  degrader  list  for  the 
Stryker  platform,  shown  in  Figure  1,  is  based  on  the  analysis  results  detailed  in  the  ‘SBCT 
Vehicle  Degrader  Analysis  for  the  Stryker  Platform’  report  that  was  completed  on  15  August 
201 1 .  The  full  report  can  be  obtained  from  Mr.  Robert  Scheltema,  at  PM-SBCT. 
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Figure  1 :  Stryker  Plat 
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The  first  two  columns  are  the  vehicle  system  and  component/subsystem  description.  The  next 
column  provides  the  ranking  results  for  the  2004  -  2010  DMIS  average  part  replacement  data. 
The  fourth  and  fifth  columns  provide  the  mission  criticality  ratings  (1  -  failure  has  a  negligible 
effect  on  functionality,  5  -  failure  results  in  complete  loss  of  functionality)  and  mission  reliability 
ratings  (1  -  most,  5  -  least).  The  sixth  column  indicates  whether  there  is  an  on-board  or  at- 
platform  diagnostics  capability  for  each  component  or  sub-system.  The  final  three  columns 
indicate  time  and  difficulty  to  diagnose  (1  -  effective  diagnostics,  5  -  less  effective  diagnostics), 
time  and  difficulty  to  repair  (1  -  short  repair  time,  5  -  long  repair  time),  and  relative  cost  to 
maintain  (1  -  low  repair/replacement  cost,  5  -  high  repair/replacement  cost).  For  a  more  detailed 
description  of  the  rankings  see  pages  14-15. 


The  final  step  in  the  degrader  process  involved  conducting  an  analysis  known  as  failure  modes, 
effects  and  criticality  analysis  (FMECA)  for  the  degrader  components.  This  analysis  was 
conducted  using  the  comments  from  the  DMIS  part  replacement  data  to  determine  the  failure 
modes  that  are  occurring  for  each  degrader  component  and  subsystem.  This  vehicle  degrader  - 
potential  health  management  solutions  analysis  provided  a  recommended  list  of  sensors  that 
either  currently  exist  on  the  platform  or  would  need  to  be  added  to  enable  a  diagnostic  or 
predictive  capability  for  each  system  or  component  identified  as  a  high  probability  degrader.  In 
order  to  provide  the  degrader  analysis  conclusion  results  in  a  concise  format,  summary  tables 
were  created.  The  summaries  include  a  table  for  the  diesel  engine  assembly,  the  drive  train 
system,  the  electrical  power  generation  and  storage  system,  and  the  height  management 
system  and  hydraulic  system,  which  are  included  in  the  degrader  analysis  final  report.  A 
summary  of  the  conclusions  and  recommendations  from  the  report  are  provided  below. 
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The  most  significant  and  highest  occurrence  failure  mode  for  the  diesel  engine  is  a  low  engine 
oil  level  from  either  engine  oil  leaks  or  non-replenishment  of  the  fluid.  A  general  low  engine  oil 
condition  is  detectable  with  the  existing  embedded  diagnostics  using  the  oil  temperature  switch 
and  oil  pressure  switch  that  provide  fault  codes  as  well  as  the  coolant  temperature  data.  A 
more  direct  diagnostic  capability  as  well  as  a  predictive  capability  would  require  the  addition  of 
an  oil  level  sensor. 

The  most  significant  and  highest  occurrence  failure  mode  for  both  the  differentials  and  the 
transfer  case  is  low  lubrication  oil  level  from  either  leaks  or  non-replenishment  of  the  fluid.  A 
low  lubrication  oil  condition  for  the  differentials  and  the  transfer  case  is  not  detectable  with  the 
existing  embedded  diagnostics  and  there  are  no  existing  sensors  installed  on  the  vehicle  for 
monitoring  the  health  of  the  differentials  or  transfer  case.  A  diagnostic  capability  as  well  as  a 
predictive  capability  would  require  the  addition  of  a  single  vibration  sensor  (accelerometer) 
applied  to  each  differential  and  transfer  case. 

The  most  significant  and  highest  occurrence  failure  mode  for  the  alternator,  batteries  and 
voltage  regulator  is  charging  issues  that  cannot  be  completely  detected  by  the  existing  vehicle 
embedded  capability.  The  alternator  and  voltage  regulator  would  require  the  addition  of  a 
current  sensor  with  a  current  and  voltage  trending  algorithm  for  a  diagnostic  capability  and  a 
predictive  capability  for  the  alternator  could  be  implemented  with  current  signature  analysis 
techniques.  For  the  batteries,  it  is  recommended  that  the  existing  U.S.  Army  at-platform  battery 
diagnostic  tools  be  fully  utilized  by  the  maintainers  before  an  embedded  solution  is  implemented 
on  the  platforms. 

The  most  significant  and  highest  occurrence  failure  mode  for  the  height  control  manifold  in  the 
height  management  system  is  nitrogen  gas  leaks.  The  existing  embedded  diagnostics  has  a 
partial  capability  to  detect  this  failure  mode  using  fault  codes.  In  order  to  provide  a 
comprehensive  leak  detection  capability  as  well  as  a  predictive  indication  it  is  recommended 
that  a  pressure  sensor  be  installed  on  both  the  low  and  high  pressure  sides  of  the  system  in 
addition  to  or  as  a  replacement  for  the  existing  pressure  switches. 

The  most  significant  and  highest  occurrence  failure  mode  for  the  hydraulic  system  is  the  loss  of 
hydraulic  fluid.  The  loss  of  fluid  is  a  direct  consequence  of  hydraulic  fluid  leaks  that  can  be 
generally  detected  with  the  existing  reservoir  level  switch  but  the  specific  source  of  the  leaking 
fluid  failure  mode  cannot  be  determined  (i.e.  isolated)  with  the  existing  vehicle  sensors.  The 
implementation  of  an  embedded  fault  isolation  or  predictive  capability  for  hydraulic  fluid  leaks  is 
not  recommended  for  this  application  due  to  low  effectiveness  of  the  current  technology. 

Additional  diagnostic  capabilities  using  parametric  data  from  the  existing  vehicle  sensors  could 
be  developed.  These  capabilities  include  an  oil  life  condition  algorithm  that  provides  an 
actionable  and  definitive  indication  of  when  the  oil  should  be  changed  using  engine  speed  and 
coolant  temperature  sensors.  In  addition,  an  engine  performance  and  general  health  indication 
using  a  data  fusion  technique  with  parametric  data  from  multiple  existing  sensors  including 
engine  speed,  boost  pressure,  engine  coolant  temperature,  fuel  rate,  and  manifold  temperature 
sensors  could  be  developed.  Finally,  an  electrical  power  generation  system  general  health 
indication  could  be  developed  using  parametric  data  from  the  engine  speed  and  voltage 
sensors.  The  approach  would  provide  a  course  health  assessment  of  the  electrical  power 
generation  system  including  the  alternator,  voltage  regulator  and  batteries. 

The  results  of  the  degrader  analysis  provide  a  list  of  existing  platform  sensors  as  well  as  a  list  of 
potential  additional  sensors  that  could  be  added  to  the  vehicle.  Some  of  these  sensors  were 
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developed  and  added  to  the  test  vehicle  for  this  program  but  not  all  of  the  potential  additional 
sensors  were  implemented.  This  report  will  describe  the  sensors  that  were  developed  and 
added  to  the  platform  for  this  program. 

2.0  Overview  of  the  SEDCAS  Program: 

The  SBCT  Embedded  Data  Collection  and  Analysis  System  (SEDCAS)  program  involves  the 
collection  and  analysis  of  individual  vehicle  usage  and  performance  data  to  improve  the  vehicle 
fleet  sustainment  and  condition  based  maintenance  of  Stryker  Brigade  Combat  Team  vehicles 
including  the  Stryker  and  HEMTT  A4  platforms.  The  56th  Stryker  Brigade  Combat  Team  of  the 
28th  Infantry  Division  of  the  Pennsylvania  Army  National  Guard  (PAARNG)  was  selected  as  the 
test  unit  for  this  program.  A  high  level  operational  view  of  the  SEDCAS  program  is  shown  in 
Figure  2. 
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Figure  2:  SEDCAS  Operational  View 


The  focus  of  the  program  was  to  utilize  existing  GOTS  (primary  objective)  and  COTS 
(secondary  objective)  technologies  to  enable  an  automated  health  management  and  condition 
based  maintenance  capability  for  the  Stryker  platforms.  The  automated  system  is  designed  to 
operate  with  any  ground  vehicle  that  has  a  SAE  standard  digital  data  bus  including  the  Stryker, 
HEMTT,  FMTV,  HET,  M915  and  MRAPS.  As  shown  in  Figure  2,  the  on-platform  sensors  and 
data  for  assessing  platform  health  includes  the  existing  vehicle  sensors  and  fault  codes  as  well 
as  the  addition  of  a  fuel  sensor  and  an  electrical  power  sensor.  A  maintenance  support  device 
(MSD  v3)  laptop  computer  was  installed  on  five  Stryker  platforms  and  one  HEMTT  A4  platform 
to  provide  the  capability  to  collect  and  store  vehicle  digital  bus  data  in  the  Army  Bulk  CBM  Data 
(ABCD)  format.  The  data  from  each  platform  is  automatically  transferred  from  each  vehicle  to 
wireless  access  points  located  at  the  PAARNG  maintenance  facility  in  State  College,  PA  using 
the  encrypted  FIPS  140-2  protocol.  The  access  points  store  the  data  from  all  of  the  vehicles 
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and  transfers  the  data  to  servers  located  at  ARL  Penn  State  facility  in  State  College,  PA  using 
either  a  U.S.  Army  standard  CAISI  network  or  a  commercial  cellular  network  to  demonstrate  the 
feasibility  of  either  approach.  The  vehicle  data  is  collected  and  stored  at  ARL  Penn  State  data 
warehouse  that  is  designed  to  emulate  the  LOGSA  CBM  data  warehouse.  The  data  processing 
architecture  is  employed  to  conduct  automated  data  analytics  including:  fleet  usage;  vehicle 
performance  and  fuel  usage;  and  using  fault/failure  codes  to  conduct  condition  based 
maintenance.  The  vehicle  data  and  the  results  of  the  data  analysis  are  presented  in  a  vehicle 
fleet  information  interface  that  is  designed  to  support  vehicle  fleet  health  management  and 
condition  based  maintenance.  This  information  will  be  used  to  optimize  operations  and  conduct 
focused  and  tailored  maintenance  on  Stryker  platforms.  This  effort  will  support  the  transition 
from  contractor  logistic  support  to  organic  maintenance  performed  by  the  U.S.  Army. 

3.0  Platform  Data  and  Sensor  Development: 

The  embedded  data  collection  system  gathers  vehicle  data  from  the  SAE  J1708  (old  standard) 
digital  data  bus.  In  order  to  facilitate  the  integration  of  additional  sensors  to  the  platforms,  ARL 
Penn  State  installed  a  SAE  J1939  (new  standard)  controller  area  network  (CAN)  digital  data  bus 
specifically  to  support  the  additional  sensors  described  below. 

3. 1  Existing  Vehicle  Sensors  on  the  Digital  Data  Bus: 

The  platform  has  data  from  many  sensors,  alerts  and  fault  codes  that  exist  on  the  J1708  data 
bus.  Data  was  gathered  from  the  list  shown  in  Table  1. 


Table  1:  Platform  Sensors,  Alerts  and  Fault  Codes 


Engine 


•  Engine  Speed 

•  Engine  Load 

•  Boost  Pressure 

•  Accelerator  Pedal  Position 

•  Coolant  Temp 

•  Fuel  Consumption  Rate 

•  Fuel  Econ 

•  Power  Take-Off  Information 

•  Rated  Engine  Power 
•Total  Times  (Engine  Hours, 

Driving  Time,  Fuel  Used,  Idle 
Hours,  Idle  Fuel  Used,  Idle  Time 
Percentage) 


Transmission 


•  Oil  Temperature 

•  Output  Shaft  Speed 

•  Transmission  Range  Attained 

•  Transmission  Range  Selected 


Brakes 


•ABS  Brake  Control  Status 
•ABS  Retarder  Control  Status 
•ABS  Warning  Lamp  Status 
•ATC  Spin-OutSignal  Detection 
•ATC  Status  Lamp 
•Battery  Potential 
•Hard  Braking  Event 
•Rapid  Accel  Event 
•Trip  Drive  Time 
•Vehicle  Speed 
•Wheel  Speeds 


Alerts  and  Faults 


•Alert  Name 
•Alert  Reason 

•Alert  Severity  Code  and  Color 
•Alert  Time 

•Fault  Amber  Warning  Lamp 
•Fault  Description 
•Fault  FMI 

•Fault  Malfunction  Indicator  Lamp 
•Fault  Status 
•Fault  Time 
•Fault  Count 
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3.2  Universal  Fuel  to  CAN  Adaptor: 

Since  the  Stryker  platforms  do  not  have  the  capability  to  provide  the  fuel  level  sensor  data  to  the 
J1939  bus,  ARL  Penn  State  developed  and  built  a  Universal  Fuel  to  CAN  (UFC)  adaptor  that 
converts  the  analog  fuel  level  sensor  data  into  a  J1939  message  that  enables  the  ability  to 
record  the  fuel  level  data  during  vehicle  operations  as  shown  in  Figure  3. 


Figure  3:  Universal  Fuel  to  CAN  (UFC)  Adaptor 

The  Stryker  fuel  sensor  is  a  current  sink.  The  fuel  gauge  intermittently  sources  current,  once 
every  12  seconds.  The  sensor  sinks  current  proportional  to  the  fuel  level  on  the  sensing 
element.  The  UFC  is  shunted  between  the  gauge  and  sensor.  The  UFC  adaptor  design 
accommodates  other  fuel  sender  /  gauge  styles  widely  used  across  other  military  platforms  such 
as  current  loop,  Pulse  Width  Modulated  signal  (PWM)  and  potential  (voltage)  type.  The  adaptor 
outputs  message  on  SAE  J1939,  (PGN65276  and  SPN  96)  at  a  one  second  update  rate  with 
field  upgradeable  firmware.  The  adaptor  has  a  form  factor  of  2.00”  x  3.25”  x  0.5”  and  the 
enclosure  is  epoxy  filled  and  environmentally  sealed  with  a  LED  status  that  indicates  functioning 
or  disconnected  or  invalid  sensor  data.  Each  platform  in  the  SEDCAS  program  has  an 
embedded  UFC  adaptor. 

3.3  Advanced  Electrical  Power  Sensor: 

In  order  to  monitor  the  vehicle  electrical  power  system  performance  data  and  provide  an 
embedded  health  management  capability  an  advanced  electrical  power  (AEP)  sensor  was 
develop  and  built  as  shown  in  Figure  4. 
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Figure  4:  Advanced  Electrical  Power  Sensor 


The  sensor  is  designed  so  that  the  same  sensor  design  can  be  used  to  monitor  the  vehicle 
alternator  and  each  battery  string  with  individual  sensors.  The  sensor  is  designed  to  measure 
and  record  voltage,  current  and  temperature  and  output  messages  on  the  J1939  CAN  bus 
(PGN65300  -  PGN65317)  at  a  one  second  update  rate.  The  measurements  include  minimum, 
maximum,  mean,  and  rms  of  the  current  and  voltage  as  well  as  mean  temperature.  The  power 
cycle  measurements  include  minimum  voltage,  maximum  current,  and  elapsed  time.  The 
lifetime  measurements  include  total  current  and  elapsed  time.  The  sensor  can  store  30  minutes 
of  collected  data  before  publishing  to  the  CAN  bus  and  it  has  field  upgradeable  firmware. 

The  AEP  sensor  implementation  configuration  for  the  alternator  is  shown  in  Figure  5. 


Alternator 


Master  Power 


GND 


Voltage  Monitor 


CAN H 


CAN L 


GND 


V+ 


GND 


Battery  Box 


Figure  5:  AEP  Sensor  Implementation  for  the  Alternator 

The  alternator  power  lead(s)  pass  through  sensor  and  the  sensor  is  powered  by  a  master  power 
switch.  The  voltage  monitor  measures  alternator  output  voltage. 

The  AEP  sensor  implementation  configuration  for  each  24  volt  battery  string  is  shown  in  Figure 
6. 


UNCLASSIFIED 


UNCLASSIFIED 


Master  Power 


Battery  1 


Battery  2 


Figure  6:  AEP  Sensor  Implementation  for  the  Battery  String 

The  voltage  monitors  measures  both  battery  voltages  and  the  voltage  monitors  ‘disconnect’ 
when  powered  down. 

Each  platform  in  the  SEDCAS  program  has  embedded  advanced  electrical  power  sensors. 

3.4  Differential  Lubrication  Level  Sensor: 

In  order  to  address  the  differential  lubrication  loss  failure  mode,  we  explored  various  sensor 
solutions  for  this  critical  failure  mode.  There  are  many  technology  choices  for  conducting 
lubrication  loss  diagnostics  on  differentials.  A  simple  first  assessment  for  determining  the  best 
method  for  detecting  a  loss  of  lubrication  is  to  measure  the  level  directly  using  a  level 
transmitter.  Due  to  space  constraints  within  the  differential  and  reading  inaccuracies  because  of 
fluid  movement  this  choice  is  considered  to  have  a  low  effective  feasibility. 

Another  method  is  to  look  for  effects  of  lubrication  loss,  like  a  temperature  increase  of  the 
differential  case.  Temperature  monitoring  can  be  an  effective  health  monitoring  technique  but  it 
is  limited  in  that  it  has  a  slow  reaction  time  relative  to  the  fault  degradation  time  of  mechanical 
system  components.  Damage  to  the  gears  and  bearings  can  occur  between  when  the 
lubrication  loss  occurs  and  the  differential  sensor  shows  a  significant  increase  in  temperature. 
Temperature  does  not  provide  an  early  indication  of  lubrication  loss  and  it  is  not  effective  for 
detecting  and  diagnosing  gear  and  bearing  faults  in  the  differential.  Temperature  monitoring  by 
itself  may  not  be  a  good  diagnostic  indicator  but  it  could  provide  non-commensurate  data  for 
sensor  fusion  and  prognostic  techniques. 

One  of  the  most  effective  techniques  for  diagnosing  mechanical  system  faults  is  vibration 
analysis.  Many  vibration  based  techniques  have  proven  to  be  sensitive  and  early  indicators  of 
bearing  and  gear  faults  in  mechanical  systems.  Since  vibration  sensors  have  been  used  to 
detect  bearing  and  gear  faults  in  differentials,  their  use  in  the  detection  of  low  lubrication  level 
would  provide  for  a  much  simpler  and  efficient  multi-purpose  sensor  implementation.  The  focus 
of  this  work  is  to  determine  if  vibration  analysis  can  be  an  effective  indictor  of  low  lubrication 
level. 

We  gathered  data  from  both  a  Stryker  differential  and  a  HEMTT  differential,  processed  the  data 
and  conducted  data  analysis  to  evaluate  the  correlation  between  the  vibration  measured  by  the 
transducer  and  the  differential  lubrication  level.  Based  on  the  analysis,  we  were  able  to  create 
an  algorithm  that  uses  vibration  data  from  the  differential  to  determine  the  lubrication  level  as 
shown  in  Figure  7. 
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Figure  7:  Curve  Fit  of  Differential  Vibration  data  as  a  Function  of  Vehicle  Speed 

The  data  in  Figure  7  shows  the  results  of  2nd  order  polynomial  curve  fits  for  both  the  100%  full 
lubrication  level  vibration  data  represented  by  the  blue  circles  and  the  0%  empty  lubrication 
level  vibration  data  represented  by  the  green  circles.  The  vibration  data  in  g’s  is  the  RMS  (root 
mean  squared)  value  over  a  narrow  frequency  range  that  was  selected  for  optimum  sensitivity 
to  lubrication  level  and  it  is  plotted  against  the  vehicle  speed  in  miles  per  hour  (mph).  The 
dashed  lines  for  each  curve  fit  represents  two  standard  deviations  (i.e.  95%  confidence  bounds) 
for  the  curve  fit. 

What  the  data  shows  is  that  above  a  vehicle  speed  of  25  mph,  there  is  an  indication  of  the 
lubrication  level  for  differential  that  changes  as  a  function  of  vehicle  speed.  As  the  vehicle 
speed  increases  the  ability  to  distinguish  between  the  levels  is  greater  which  provides  increased 
confidence  in  the  level  indication.  Based  on  the  results  of  the  algorithm  development,  we  are 
proposing  to  develop  a  digital  sensor  that  can  implement  this  algorithm  and  be  attached  to  the 
differential  to  provide  a  lubrication  level  capability.  This  work  would  be  conducted  through  a 
future  effort. 

4.0  On-Platform  Digital  Source  Collection  System: 

The  program  functional  requirements  for  the  vehicle  embedded  digital  source  collection  (DSC) 
system  includes  the  ability  to  interface  with  the  vehicle  digital  data  buses,  collect  vehicle  digital 
bus  data,  conduct  short  term  data  storage  (~  three  weeks),  enable  conversion  of  the  data  into 
the  standard  Army  Bulk  CBM  Data  (ABCD)  format,  and  CAISI  wireless  data  transfer  from 
vehicle  to  remote  wireless  access  points  using  FIPS  140-2  data  encryption. 

4. 1  Digital  Source  Collector: 

The  DSC  data  collection  and  storage  device  that  was  used  for  this  program  is  the  Miltope 
Maintenance  Support  Device  (MSD  V3)  that  is  Government  Off-The-Shelf  (GOTS)  equipment. 
The  reason  that  the  MSD  v3  was  selected  as  the  DSC  device  for  this  program  is  because  the 
U.S.  Army  has  plans  to  integrate  an  MSD  standard  laptop  computer  to  each  Stryker  platform  to 


UNCLASSIFIED 


UNCLASSIFIED 


host  the  IETM  and  potentially  serve  as  a  ground  digital  logbook.  This  SEDCAS  program  utilized 
the  MSD  and  configured  it  to  serve  the  additional  purpose  of  a  digital  source  collection  device 
that  could  enable  a  condition  based  maintenance  capability  for  the  platforms. 

The  components  of  the  digital  source  collection  system  include  the  MSD  v3,  Noregon  JPRO 
Military  Diagnostics  software  and  a  Noregon  DLA+  bus  adaptor  as  shown  by  the  brown 
components  in  Figure  8.  The  components  shown  in  blue  are  the  additional  sensors  that  were 
described  in  the  previous  section. 


Figure  8:  Digital  Source  Collection  System  and  Sensors 


The  MSD  v3  laptop  computer  that  uses  the  Windows  7  operating  system,  was  configured  as  a 
digital  source  collection  device  with  the  implementation  of  the  Noregon  JPRO  Military  software 
that  enables  the  ability  to  collect  data  from  the  J1939  and  J1708  data  buses.  This  software  is 
based  on  a  commercial  fleet  vehicle  software  product  that  was  adapted  for  military  use  with 
requirements  and  funding  for  the  adaptation  being  provided  by  U.S.  Army  AMSAA.  We  selected 
this  software  for  this  program  because  it  has  been  functionally  validated  by  AMSAA  through 
their  sample  data  collection  program  and  it  is  considered  GOTS  technology.  This  program 
provided  the  technical  direction  and  the  funding  to  incorporate  an  ABCD  data  format  conversion 
capability  into  the  JPRO  software. 

The  MSD  gathered  data  from  the  J1708  and  J1939  digital  data  buses  with  the  utilization  of  a 
data  bus  protocol  adaptor.  There  are  several  commercially  available  protocol  adaptors  but  the 
Noregon  DLA+  bus  adaptor  was  selected  for  this  effort  because  we  were  using  the  Noregon 
JPRO  Military  software  and  their  adaptor  allowed  direct  compatibility  with  their  software.  The 
integration  of  the  protocol  adaptor  into  the  DSC  system  is  shown  in  both  Figure  8  and  9. 

In  order  to  enable  the  MSD  to  boot-up  when  main  vehicle  power  was  applied  to  the  device,  the 
software  BIOS  was  updated  by  the  MSD  manufacturer  (Miltope)  to  enable  this  capability.  ARL 
Penn  State  created  an  MSD  power-off  application  that  enabled  a  ‘graceful’  shut  down  capability 
when  all  of  the  required  functions  (i.e.  data  collection  and  transmission  tasks)  were  completed 
by  the  MSD  at  the  end  of  each  mission. 
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Figure  9:  DSC  System  Support  Components 
MSD  Lessons  Learned: 

There  are  two  factors  that  need  to  be  addressed  to  effectively  utilize  an  MSD  as  an  embedded 
DSC. 

1.  Implement  the  update  BIOS  for  all  of  the  MSD’s  being  integrated  to  the  platform  to 
enable  the  MSD  to  boot-up  when  main  vehicle  power  is  applied  to  the  device. 

2.  It  is  recommended  that  the  current  standard  USB  connectors  on  the  MSDv3  be 
upgraded  to  accept  hardened  stud  mounted  USB  connectors  as  shown  in  Figure  10. 


Figure  10:  Hardened  Stud  Mounted  USB  Connectors 
4.2  Wireless  Data  Transfer: 

The  data  that  is  collected  on  the  MSD  was  stored  until  the  vehicle  came  into  range  of  a  wireless 
access  points  that  are  located  at  the  State  College  PAARNG  Maintenance  Facility.  The 
wireless  data  transfer  capability  was  implemented  with  the  existing  802. 1 1  b/g  wireless  that  is 
resident  on  the  MSD  with  the  addition  of  a  USB  wireless  extension  antenna  (shown  in  Figure  9) 
that  was  placed  outside  the  vehicle  hull.  The  FIPS  140-2  encryption  of  the  data  was 
implemented  through  a  standard  embedded  function  in  the  Windows  7  operating  system. 

The  organization  and  synchronization  of  the  data  downloads  from  each  vehicle  to  the  access 
points  was  facilitated  with  GoodSync  software  that  was  installed  on  each  platform  DSC  and  the 
access  points.  This  COTS  product  was  utilized  for  this  program  due  to  its  relatively  low  cost 
and  high  reliability.  The  ARMY’S  future  plans  are  to  handle  the  synchronization  function  and 
data  downloads  using  a  GOTS  product  under  development  by  LOGSA  named  Common 
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Information  Management  Services  CIMS).  This  will  replace  GoodSync  in  the  SEDCAS  system 
when  it  is  available  in  the  future. 

5.0  Off-Platform  Data  Transmission  System: 

The  wireless  local  area  network  (WLAN)  data  transmission  capability  that  moves  data  from  each 
platform  to  the  ARL  Information  Warehouse  (ARL  IW)  located  at  ARL  Penn  State  consists  of  a 
U.S.  Army  standard  (GOTS)  portable,  weatherproof  WLAN  network  communication  system 
called  Combat  Service  Support  Automated  Information  Systems  Interface  (CAISI).  The  CAISI 
system  consists  of  a  802. 1 1  b/g  wireless  access  point  that  receive  data  from  each  platform,  a 
switch,  security  gateway  and  a  bridge  module  that  transfers  the  data  from  the  access  point  to 
the  ARL  IW.  The  CAISI  system  has  a  maximum  range  of  32  miles  point  to  point.  For  this 
program  we  used  a  directional  antenna  at  each  end  point  with  an  omnidirectional  intermediate 
antenna  at  the  midpoint  to  overcome  an  elevation  peak  in  the  middle  of  our  5.5  mile  data  hop. 
In  addition  to  the  CAISI  wireless  network  system,  we  integrated  a  data  buffer  with 
synchronization  capability  with  the  access  point.  We  also  implemented  an  additional  functional 
bridge  module  using  commercial  cellular  wireless  solution  and  developed  a  potential  future 
SATCOM  data  transmission  capability  as  shown  in  Figure  11. 


When  a  platform  is  in  transmission  range  of  an  access  point/bridge  module  located  at  the 
PAARNG  Maintenance  Facility  in  State  College,  PA,  the  on-platform  MSD  digital  source 
collection  system  with  GoodSync  software  automatically  downloads  stored  data  to  the  CAISI 
access  point.  The  access  point  has  an  embedded  computer  that  supports  the  GoodSync 
software  and  serves  as  a  data  buffer  to  provide  short  term  data  storage  for  all  of  the  platforms 
that  it  serves  until  the  data  can  be  transferred  to  the  ARL  IW  located  at  ARL  Penn  State. 
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A  survey  was  conducted  to  validate  the  configuration  of  the  access  points  at  the  PAARNG 
Maintenance  Facility.  Initial  testing  showed  that  there  were  ‘dead  spots’  when  only  one  access 
point  was  used,  so  two  access  points  were  implemented  for  this  compound.  The  location  of  the 
two  CAISI  access  point/bridge  modules  and  the  wireless  data  transmission  test  points  are 
shown  in  Figure  12.  Test  points  10,  11,  and  12  are  not  shown  on  the  map  because  they  are 
located  at  extreme  distances  from  the  access  points,  near  the  limit  of  their  range. 


Figure  12:  Wireless  Data  Transmission  Test  Map 


The  survey  consisted  of  wirelessly  transferring  data  from  a  test  vehicle  equipped  with  a  DSC 
system  to  the  access  points  from  each  of  the  locations  indicated  in  Figure  12.  The  results  of  the 
data  analysis  that  included  signal  strength,  link  quality,  distance  from  each  access  point  and 
elevation  from  sea  level  for  each  of  the  test  points  are  shown  in  Table  2. 
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Table  2:  Wireless  Survey  Results  with  Two  Access  Points 


Location 

Signal 

Strength  (%) 

Link 

Quality  (%) 

Distance 
from  API  / 
AP2  (m) 

Elevation 

(m) 

0 

86 

76 

85/95 

372 

1 

76 

73 

188  /  60 

368 

2 

74 

74 

239/72 

364 

3 

86 

87 

145  /  55 

368 

4 

82 

88 

78/125 

370 

5 

82 

87 

50/124 

370 

6 

84 

89 

42/126 

371 

7 

72 

75 

82/156 

372 

8 

88 

88 

122/104 

372 

8x 

84 

85 

145/23 

367 

9 

62 

45 

260/103 

362 

10 

0 

0 

616/454 

352 

11 

0 

0 

865/706 

350 

12 

0 

0 

1,147/1,049 

356 

The  survey  data  shown  in  Table  2  indicates  that  all  of  the  test  locations  within  the  compound 
provide  relatively  high  signal  strength  and  link  quality  with  the  exception  of  the  extreme  distance 
test  points  10,  1 1  and  12  that  had  zero  signal  strength  and  link  quality. 

Once  the  vehicle  data  is  transferred  to  the  access  point  data  buffer,  then  the  bridge  portion  of 
the  device  can  send  the  data  to  the  ARL  Penn  State  data  repository  using  the  CAISI  bridge 
module  capability  as  shown  in  Figure  1 1 .  Since  it  was  not  pre-determined  that  U.S.  Army  CAISI 
technology  would  be  available  for  this  program,  a  commercial  cellular  technology  was 
implemented  as  the  developmental  approach  for  data  transmission  to  the  ARL  IW.  The 
implementation  of  this  commercial  technology  allowed  us  to  build  an  end  to  end  capability  while 
waiting  for  the  CAISI  bridge  modules,  which  was  a  risk  reduction  activity.  For  this  approach,  a 
Verizon  Raven  X  3G  cellular  modem  device  (COTS)  with  a  Cisco  ASA  5500  Series  Adaptive 
Security  Appliance  (COTS)  that  provides  firewall  functionality  was  integrated  with  the  CAISI 
access  point  system.  A  third  potential  bridge  capability  was  also  partially  developed  to  allow  for 
the  future  integration  of  a  VSAT  data  transfer  capability.  Since  a  VSAT  system  was  not 
available  for  this  effort  it  was  not  implemented. 

6.0  ARL  Penn  State  Data  Server: 

Once  the  vehicle  data  is  received  by  the  bridge  module  located  at  ARL  Penn  State,  the  data  is 
ingested  into  the  ARL  Information  Warehouse.  This  server  system  was  designed  to  be  similar 
to  the  Common  CBM  Data  Warehouse  that  is  part  of  the  LOGSA  Logistic  Information 
Warehouse  (LIW).  This  was  done  to  develop  ‘best  practices’  for  moving  vehicle  data  to  LOGSA 
and  to  implement  technologies  are  currently  being  developed  and  deployed  by  DoD.  The 
general  functionality  of  the  ARL  IW  is  to  automatically  analyze  individual  ABCD  files  as  they 
arrive  at  the  IW,  calculate  derived  metadata  parameters  and  usage/fault  detection  algorithms 
associated  with  each  file  and  save  the  derived  metadata  parameters  and  the  usage/fault 
detection  algorithms  to  the  IW  and  the  user  interface  Data  Mart  via  the  Metadata  Injection  web 
service  as  shown  in  Figure  13. 
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Figure  13:  System  View  for  the  ARL  Information  Warehouse 


The  specifics  of  the  ARL  IW  process  starts  with  the  vehicle  ABCD  files  being  placed  in  a  staging 
area  before  being  loaded  into  the  data  ingest  process  in  the  data  warehouse.  The  ABCD  files 
are  split  into  their  two  components  consisting  of  the  metadata,  which  is  the  textual  description  of 
the  data  file  such  as  the  vehicle  and  sensor  identification  and  the  parametric  data,  which  is  the 
actual  sensor  data.  The  metadata  portions  of  the  ABCD  file  are  stored  in  a  database  that 
enables  the  ability  to  conduct  search  queries  on  the  data.  Each  metadata  input  is  linked  to  the 
corresponding  parametric  file  that  is  stored  in  a  flat  file  storage  format.  This  provides  an 
optimum  data  search  and  storage  capability  as  defined  by  the  ABCD  format  best  practices. 

Automated  data  analysis  routines  can  then  pull  ABCD  files  and  apply  usage  and  fault  detection 
algorithms  to  convert  the  data  into  information.  Examples  of  the  information  include  trip 
distance,  time  spent  idling,  total  fuel  consumed,  fuel  consumed  at  idle,  average  speed  when 
moving,  maximum  vehicle  speed,  total  engine  revolutions  and  engine  oil  life  parameter.  The 
information  (i.e.  derived  metadata)  generated  by  the  analysis  routines  is  sent  to  the  metadata 
injection  web  service  that  sends  the  derived  metadata  to  be  stored  in  the  metadata  database 
and  also  sends  the  derived  metadata  to  the  user  interface  (Ul)  data  mart.  The  final  step  in  the 
process  involves  the  user  interface  web  service  taking  the  latest  data  from  the  Ul  data  mart  and 
inserting  it  into  the  user  interface.  All  of  these  steps  are  conducted  automatically  by  the  ARL 
IW. 
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7.0  SEDCAS  Information  Interface: 

The  Stryker  Brigade  Combat  Team  Unit  Management  Portal  information  interface  was  designed 
to  provide  individual  platform  status,  health,  fuel,  usage,  and  maintenance  information  to  the 
appropriate  information  users  to  enable  fleet  management  and  condition  based  maintenance 
capabilities.  The  unit  that  was  selected  for  this  technology  insertion  is  56th  Stryker  Brigade 
Combat  Team  of  the  28th  Infantry  Division  of  the  Pennsylvania  Army  National  Guard 
(PAARNG). 

7. 1  Use  Cases: 

The  first  step  in  the  design  of  the  user  interface  involved  identifying  the  information  users  and 
the  development  of  use  cases.  For  this  program,  the  information  users  include  the  battalion 
maintenance  officer  (BMO)  and  the  unit  maintainers. 

The  first  use  case  involves  readiness  reporting.  There  are  two  scenarios  that  were  developed 
for  this  use  case. 

1.  The  BMO  wants  to  be  periodically  advised  as  to  the  status,  health  and  condition  of  the 
vehicles  and  equipment  to  enable  the  ability  to  report  readiness  status  to  higher  command. 

2.  The  BMO  wants  to  be  periodically  advised  as  to  the  status,  health  and  condition  of  the 
vehicles  and  equipment  to  enable  proactive  management  of  the  flow  of  consumables,  parts 
supply,  and  labor  supporting  the  units  and  vehicles  in  a  streamlined  and  efficient  manner  to 
maximize  equipment  availability,  and  minimize  operational  cost. 

In  order  to  enable  this  capability  the  following  information  categories  should  be  incorporated  into 
the  information  interface: 

Vehicle  Status  -  current  state  of  vehicles  indicating  fuel  levels  and  other  indicators  of  system 
state 

Vehicle  Health  -  current  state  of  vehicles  indicating  existence  of  fault/faults,  error  codes  alarms 
or  alerts  localized  to  the  subsystem  or  component,  tailored  to  the  top  degraders  and  expressed 
in  plain  text,  not  just  numerical  codes 

Vehicle  Condition  -  current  state  of  units  and  vehicles  indicating  mission  readiness  levels 
expressed  with  both  doctrinal  symbols  and  plain  text 

The  second  use  case  involves  fleet  management  reporting.  There  is  one  scenario  that  was 
developed  for  this  use  case. 

1.  The  BMO  and  unit  maintainer  want  to  be  notified  as  to  the  vehicle  usage  and  consumption 
information  to  enable  planning,  scheduling  and  to  conduct  preventive  maintenance. 

In  order  to  enable  this  capability  the  following  information  categories  should  be  incorporated  into 
the  information  interface: 

Usage  Indicators  -  indicators  of  time  and  mileage  based  usage  and  other  indicators  that  inform 
of  wear  and  tear  on  the  vehicle  and  advise  future  need  for  scheduled  maintenance  actions. 

The  third  use  case  involves  maintenance  repair  actions.  There  is  one  scenario  that  was 
developed  for  this  use  case. 

1.  The  BMO  and  unit  maintainer  want  to  be  notified,  at  the  individual  vehicle  level,  as  to  the 
existence  of  fault/failure  indicators,  alarms/alerts  that  are  localized  to  the  subsystem  or 
component  in  order  for  me  to  align  skills,  parts  and  tools  to  quickly  and  effectively  execute 
maintenance  actions  returning  the  vehicle  to  operational  readiness. 
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In  order  to  enable  this  capability  the  following  information  categories  should  be  incorporated  into 
the  information  interface: 

Diagnostics  -  on-board  diagnostics  codes  and  plain  text  descriptions  of  the  type  and  location  of 
such  occurrence  as  soon  as  possible  after  vehicle  shut  down.  Each  incident  should  bear  a  time 
stamp  that  indicates  the  date/time  when  the  occurrence  was  caught  by  the  system. 

7.2  User  Interface  Displays: 

Based  on  the  use  cases  the  following  SBCT  (Stryker  Brigade  Combat  Team)  Unit  Management 
Portal  user  interfaces  were  designed  and  implemented.  The  functioning  web  based  application 
is  located:  http://army-cbmplus.sil.arl.psu.edu/StrykerPortal/.  A  user’s  guide  to  the  web  portal  can  be 
provided  on  request. 

User  Display  1:  The  first  display  is  a  conceptual  global  readiness  display  that  shows  the  high 
level  readiness  for  units  in  various  locations  around  the  world  shown  in  Figure  14. 


*L'  SBCT  Unit  Management  Portal 

A 


•Select  a  Division  below 


Figure  14:  Global  Readiness  View 


Though  this  is  a  prototype  display  with  simulated  data  because  we  only  have  a  few  platforms  in 
one  SBCT  instrumented,  it  is  designed  to  show  the  aggregated  non-mission  capable  (NMC), 
partial  mission  capable  (PMC)  and  full  mission  capable  levels  for  various  brigade  combat  teams 
(BCT).  This  information  is  useful  to  higher  level  command  and  control  information  customers  to 
help  inform  fleet  vehicle  readiness  levels. 


User  Display  2:  When  the  CONUS  Army  logo  (star  inside  circle)  icon  is  selected  in  Figure  14, 
the  map  will  zoom  into  the  United  States  region.  The  CONUS  unit  location  and  a  high  level 
color  coded  readiness  symbol  are  displayed  as  shown  in  Figure  15. 
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Figure  15:  CONUS  BCT  Location  and  High  Level  Readiness  View 


The  display  currently  shows  information  for  only  the  56th  SBCT  of  the  PAARNG,  which  is  the 
unit  that  was  instrumented  with  DSC  systems  for  this  program.  When  the  user  selects  a  BCT 
from  the  list  located  in  the  left  portion  of  Figure  15,  the  display  will  zoom  into  the  representative 
icons  on  the  map  for  the  selected  unit. 

User  Display  3:  The  third  display  shown  in  Figure  16  is  similar  to  the  display  in  Figure  15  but  it 
represents  the  unit  location  and  high  level  readiness  display  for  only  the  56th  PAARNG  unit. 
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Figure  16:  PAARNG  BCT  Location  and  High  Level  Readiness  View 


This  display  indicates  the  location  and  readiness  of  the  regiment  and  company  level  units  within 
the  56th  SBCT. 

User  Display  4:  The  fourth  display  shown  in  Figure  17  shows  the  company  level  readiness. 


Figure  17:  PAARNG  BCT  Location  and  High  Level  Readiness  View 
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The  information  is  presented  in  a  ‘slant  chart’  format  where  the  first  number  indicates  the  total 
number  of  each  type  of  vehicle  (i.e.  ICV  Ml  126,  RV  Ml  127,  etc.)  in  each  company  (i.e.  HHC, 
Alpha  Company,  etc.)  and  the  second  number  indicates  how  many  of  the  vehicles  are  full 
mission  capable.  The  color  coded  strip  (i.e.  red,  yellow,  and  green)  after  the  number  provides  a 
quickly  recognizable  general  indication  of  unit  readiness. 

User  Display  5:  When  the  company  icon  is  selected  on  the  map  portion  of  the  interface  in 
Figure  17,  the  general  health  and  fuel  level  status  for  individual  vehicles  is  displayed  as  shown 
in  Figure  18.  This  display  is  designed  to  be  used  by  the  operators  and  maintainers  to  quickly 
assess  fault  codes  alerts  and  fuel  level. 


SBCT  Unit  Management  Portal 
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‘Historical  data  can  be  accessed  via  the  table  below 

1  VEHICLE  ID 

HEALTH  STATUS 

TOTAL  ACTIVE  ALERTS 

FUEL  STATUS 

FUEL  LEVEL 

GALS 

LAST  REPORT  TIME  (UTC)  1 

C-6  Stryker  ICV 

0 

82% 

43.5 

2012-06-12  18:12:33 

C-1 2  Stryker  ICV 

0 

00Q0QD0Q00 

87% 

46.0 

2012-06-11  10:59:00 

C-22  Stryker  ICV 

0 

BlllBiHIII 

97% 

51.3 

2012-08-10  21:48:33 

C-24  Stryker  ICV 

• 

3 

100% 

53.0 

2012-08-10  18:43:08 

C-32  Stryker  ICV 

0 

100% 

53.0 

2012-08-10  18:02:06 

C-34  Stryker  ICV 

0 

100% 

53.0 

2012-08-10  18:00:46 

NMC  ■  PMC  A  PMC 
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Figure  18:  Vehicle  Health  and  Fuel  Information 


The  display  includes  health  status  represented  by  a  green,  yellow  or  red  symbol  that  is  based 
on  the  total  active  alerts.  The  display  also  shows  a  fuel  level  indication  through  a  gauge,  as  a 
percent  level  and  by  number  of  gallons  with  the  last  report  time  and  date  stamp  in  universal  time 
code  (UTC)  format  for  each  individual  vehicle.  The  alert  and  fuel  data  of  this  information  display 
is  populated  by  the  vehicle  sensor  data  that  is  collected  by  the  DSC  system  from  each  vehicle. 

User  Display  6:  When  a  health  status  icon  for  an  individual  vehicle  is  selected  from  the  display 
in  Figure  18,  the  alert  history  information  for  that  vehicle  is  displayed.  The  table  in  Figure  19 
shows  the  alert  history  for  each  platform.  This  display  is  designed  to  enable  the  maintainers  to 
assess  the  condition  of  individual  platforms  based  on  the  faults  codes  so  that  they  can  better 
manage  their  maintenance  activities  including  allocating  the  appropriate  maintainer  and  tool 
resources  for  each  platform  that  requires  maintenance. 
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1  ALERT 

SEVERITY 

CODE 

TIME  OCCURRED 

ALERT  STATUS 
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Fault  from  Engine 

100 

FAULT 
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[ACTIVE] 
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100 

FAULT 

08/08/2012  1  3:19:12 
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Battery  voltage  low 

70 

BVL 

08/09/2012  15:21:53 

cleared 

Engine  underspeed 

60 

EU 

08/09.2012  15:21:53 

cleared 

VIN  mismatch 

0 

VINM 

08/09/2012  14:56:21 

cleared 

Battery  voltage  low 

70 

BVL 

08/092012  14:52:16 

cleared 

VIN  mismatch 

0 

VINM 

08/09/2012  14:36:40 

cleared 

VIN  mismatch 

0 

VINM 

08/092012  14:13:18 

cleared 

VIN  mismatch 
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VINM 

08/09/2012  13:57:58 
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VINM 
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cleared 

VIN  mismatch 

0 
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08/08/2012  13:23:27 
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Figure  19:  Individual  Vehicle  Alert  History 


The  alerts  are  generated  from  built-in-tests  (BIT)  that  are  integrated  into  the  vehicle  and 
published  to  the  J1708  bus  by  the  respective  faulted  components.  The  display  table  provides 
the  vehicle  ID,  an  alert  description,  severity  of  the  alert,  alert  code,  the  time  stamp  and  the  alert 
status  (i.e.  active,  inactive  and  cleared).  Each  active  alert  can  be  selected  and  cleared  by  a 
maintainer  who  is  logged  into  the  interface,  once  the  fault  code  has  been  appropriately 
addressed. 

User  Display  7:  When  a  fuel  status  is  selected  for  an  individual  vehicle  from  the  display  in 
Figure  18,  the  fuel  level  history  information  for  that  vehicle  is  displayed  as  shown  in  the  plot  in 
Figure  20. 
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Figure  20:  Individual  Vehicle  Fuel  Level  History 


The  fuel  level  history  display  provides  a  data  trend  plot  of  the  fuel  level  that  is  provided  by  each 
vehicle  over  a  user  selected  date  range.  Individual  fuel  level  data  points  can  be  selected  to 
provide  the  level  in  gallons,  percentage  and  the  time  and  date  stamp.  This  data  can  be  used  to 
better  understand  vehicle  fuel  consumption  profiles  to  manage  the  resupply  of  fuel  to  individual 
vehicles. 


User  Display  8:  The  eighth  display  provides  individual  vehicle  usage  information  as  shown  in 
Figure  21 . 
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•Historical  data  can  be  accessed  via  the  table  below 


START  DATE:  2012-03-24  00:00:00 


END  DATE:  2012-08-21  14:23:13 


VEHICLE  D 

eng  hrs  idle 

eng  hrs  total 

distance  (mi) 

avg  fuel  rate  idle 

avg  fuel  rate 

fuel  econ  (mpg) 

eng  oil  life  (%) 

eng  oil  life  timestamp  (utc) 

C-6  Stryker  ICV 

5.50 

6.90 

10.58 

1.86 

1.84 

0.83 

98.4 

2012-06-12  17:47:48 

C-12  Stryker  ICV 

1.95 

1.75 

0.13 

1.01 

1.16 

0.06 

0 

0001-01-01  00:00:00 

C-22  Stryker  ICV 

1.30 

1.25 

0 

1.40 

1.55 

0 

0 

0001-01-01  00:00:00 

C-24  Stryker  ICV 

13.25 

30.25 

0.16 

0.41 

0.18 

0.03 

93.7 

2012-06-12  17:19:59 

C-32  Stryker  ICV 

1.60 

1.75 

0.20 

1.69 

1.60 

0.07 

0 

0001-01-01  00:00:00 

C-34  Stryker  ICV 

1.20 

1.50 

0.15 

1.98 

1.65 

0.06 

0 

0001-01-01  00:00:00 
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Figure  21:  Individual  Vehicle  Usage  Information 


The  usage  display  provides  the  engine  hours  at  idle,  the  total  engine  hours,  the  vehicle  distance 
in  miles,  the  average  fuel  rate  at  idle  in  gallons  per  hour  (GPH),  the  total  average  fuel  rate  in 
GPH,  and  the  fuel  economy  in  miles  per  gallon  (MPG).  All  these  parameters  can  be  provided 
over  a  user  selected  date  range.  In  addition,  the  engine  oil  remaining  life  as  a  percentage  and 
the  engine  oil  life  timestamp  is  provided.  This  display  is  designed  to  provide  the  battalion 
maintenance  officer  with  multiple  pieces  of  information.  The  first  piece  of  information  is  how 
each  individual  vehicle  is  being  utilized,  spending  most  of  its  time  idling  or  being  driven.  The 
second  piece  of  information  is  the  fuel  rate  and  fuel  economy  levels  for  each  vehicle  can  be 
compared  against  each  other  to  indicate  a  platform  that  is  not  performing  well  and  may  be  in 
need  of  maintenance.  The  third  piece  of  information  is  that  the  maintainers  can  proactively  plan 
oil  changes  based  on  remaining  oil  life  information  for  each  platform. 

User  Display  9:  When  the  distance  for  an  individual  vehicle  is  selected  from  the  display  in 
Figure  21,  the  distance  traveled  history  information  for  that  vehicle  is  displayed  as  shown  in  the 
plot  in  Figure  22. 
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Figure  22:  Individual  Vehicle  Distance  Traveled  History  Data 


The  distance  traveled  history  display  provides  a  plot  of  the  individual  vehicle  miles  traveled  for 
individual  days  over  a  user  selected  date  range.  This  information  is  useful  to  the  maintainers  to 
better  understand  which  vehicles  are  accumulating  the  most  miles  and  which  vehicles  are  being 
underutilized. 


User  Display  10:  The  maintenance  data  display  provides  individual  vehicle  actionable 
information  as  shown  in  Figure  23.  The  maintenance  display  was  designed  to  provide 
actionable  information  to  the  maintainer  for  vehicle  components  that  are  considered  vehicle 
degraders.  The  intent  is  to  provide  ‘visibility’  for  component  level  data  that  provides  a  condition 
indication  to  the  maintainer  so  that  they  can  proactively  manage  the  health  of  the  vehicles.  Not 
all  of  the  data  fields  are  populated  with  data  because  the  sensors  do  not  currently  exist  on  these 
platforms  but  we  want  to  emphasis  the  future  integration  of  sensors  for  these  degrader 
components  to  provide  this  valuable  actionable  information  to  the  maintainers. 
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1  VEHICLE  ID 

ENGINE 

ELECTRICAL 

TRANSMISSION 

DIFF/T-CASE 

LAST  REPORT  TIME  1 

oil  level 

change  oil  (hrs) 

coolant  temp 

battery  (v) 

alternator  (v) 

VR 

oil  temp 

lube  level 

UTC 

C-6  Stryker  ICV 

185 

28.1 

- 

- 

123 

- 

2012-06-12  18:15:19 

C-12  Stryker  ICV 

- 

120 

28.3 

- 

- 

100 

- 

2012-08-11  11:01:18 

C-22  Stryker  ICV 

- 

- 

106 

28.3 

- 

- 

82 

- 

2012-08-10  21:48:51 

C-24  Stryker  ICV 

- 

- 

118 

28.3 
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Figure  23:  Individual  Vehicle  Maintenance  Information 


The  maintenance  display  provides  vehicle  data  for  engine  coolant  temperature,  battery  voltage, 
and  transmission  oil  temperature  with  the  last  report  time  and  date  stamp  in  universal  time  code 
(UTC)  format. 

User  Display  11:  When  the  engine  coolant  temperature  status  is  selected  for  an  individual 
vehicle  from  the  display  in  Figure  23,  the  engine  coolant  temperature  history  for  that  vehicle  is 
displayed  as  shown  in  the  plot  in  Figure  24. 
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Figure  24:  Individual  Vehicle  Engine  Coolant  Temperature  History 


Each  parameter  on  the  maintenance  display  can  be  selected  to  provide  a  trend  plot  with  the 
parameter  history.  The  data  in  Figure  24  shows  the  engine  coolant  temperature  history  display 
that  provides  a  plot  of  the  coolant  temperature  for  individual  days  over  a  user  selected  date 
range  with  an  indication  of  the  maximum  temperature  level  as  shown  by  the  red  line.  The 
vehicle  has  a  coolant  temperature  fault  message  but  this  data  trend  provides  additional 
information  to  the  maintainers  to  help  them  assess  the  duration  of  the  temperature  exceedence 
which  provides  insight  into  the  severity  of  the  condition  and  potential  damage  to  the  engine.  The 
trend  data  also  provides  an  indication  of  the  rate  of  change  of  the  temperature  that  can  help 
them  to  better  understand  the  root  cause  of  the  coolant  exceedence  fault. 


7.3  Prototype  Concept  Displays: 

In  addition  to  the  SBCT  Unit  Management  Portal,  we  developed  a  prototype  graphical  fault 
isolation  indicator  model  for  the  Stryker  Platform  as  shown  in  Figure  25. 
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Figure  25:  Stryker  Fault  Indication  and  Isolation  Model  -  Vehicle  View 


The  intent  of  using  the  model  is  to  provide  a  straight  forward  and  direct  method  for  providing 
fault  identification  and  isolation  information  to  the  maintainer  through  the  use  of  3-D  models  that 
are  linked  to  the  fault  codes  and  condition  indication  algorithms.  One  of  the  short  comings  of 
using  text  based  fault  codes  is  it  is  difficult  to  precisely  indicate  which  component  the  fault  is 
associated  with  especially  for  common  multiple  components  such  as  differentials,  suspension 
components,  tires  and  batteries.  When  the  fault  is  indicated  through  a  3-D  model  then  the 
ability  to  correctly  identify  and  repair  the  correct  component  increases. 

The  maintainer  would  select  the  color  coded  fault  code  in  the  upper  left  corner  of  Figure  25  and 
the  model  will  zoom  to  the  component  view  as  shown  in  Figure  26. 
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Figure  26:  Stryker  Fault  Indication  and  Isolation  Model  -  Component  View 


The  zoom  capability  enables  the  ability  to  assess  the  maintenance  action  that  will  need  to  be 
implemented  to  replace  or  repair  the  component. 

The  prototype  model  will  be  potential  integrated  into  the  next  version  of  the  SBCT  Unit 
Management  Portal  and  linked  to  the  fault  codes  and  condition  indication  algorithms  through  the 
follow  on  effort  to  this  program. 
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